SQL Server 2008 : Transparent Data Encryption

The encryption of a database using TDE helps prevent the unauthorized access of data in the scenario in which physical media or backups have been lost or stolen. Transparent data encryption uses a database encryption key (DEK) for encrypting the database. The DEK is stored in the database boot record and is secured by a certificate stored in the master database. The database master key is protected by the service master key, which is in turn protected by the Data Protection API. When TDE is enabled on a database, attaching data files to another SQL Server instance or the restoring of a backup to another SQL Server instance is not permitted until the certificate that was used to secure the DEK is available.

For example, if a hard drive that contains database files is stolen, without TDE, those database files can be attached in another SQL Server instance, thus allowing access to the nonencrypted data in those files. With TDE, the data and log files are automatically encrypted, and the data within these files cannot be accessed without an encryption key. Additionally, backups of databases that have TDE enabled are also encrypted automatically. We’re all familiar with stories about how backup tapes containing sensitive information have been lost or stolen. With TDE, the data in the backup files is completely useless without also having access to the key used to encrypt that data.

The encryption and decryption of data with TDE are performed at the page level as data moves between the buffer pool and disk. Data residing in the buffer pools is not encrypted. TDE’s specific purpose is to protect data at rest by encrypting the physical files of the database, rather than the data itself. These physical files include the database file (.mdf), transaction log file (.ldf), and backup files (.bak). Data pages are encrypted as they are written from the buffer pool to the database files on disk. Conversely, the data is decrypted at the page level when the data is read in from the files on disk into the buffer pool. The encryption and decryption are done using a background process transparent to the database user. Although additional CPU resources are required to implement TDE, overall, this approach offers much better performance than column-level encryption. According to Microsoft, the performance hit averages only about 3–5%.

TDE supports several different encryption options, such as AES with 128-bit, 192-bit, or 256-bit keys or 3 Key Triple DES. You make your choice when implementing TDE.

Implementing Transparent Data Encryption

Like many encryption scenarios, TDE is dependent on an encryption key. The TDE database encryption key is a symmetric key that secures the encrypted database. The DEK is protected using a certificate stored in the master database of the SQL Server instance where the encrypted database is installed.

Implementing TDE for a specific database is accomplished by following these steps:

• Create a master key.
  
  
• Create or obtain a certificate protected by the master key.
  
  
• Create a database encryption key and protect it by the certificate.
  
  
• Configure the database to use encryption.
  
  

Listing 1 demonstrates the commands needed to encrypt the AdventureWorks2008R2 database, including the creation of a master key, certificate, and DEK protected by the certificate.

Listing 1. Encrypting the AdventureWorks2008R2 Database

USE master;
GO

--Create the master key which is stored in the master database
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'mystrongpassword$$';
GO

-- Create a certificate that is also stored in the master
-- database. This certificate will be used to encrypt a user database
CREATE CERTIFICATE MyCertificate
 with SUBJECT = 'Certificate stored in Master Db'
GO

-- Create a Database Encryption Key (DEK) that is based
-- on the previously created certificate
-- The DEK is stored in the user database
USE AdventureWorks2008R2
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyCertificate
GO
-- Turn the encryption on for the AdventureWorks2008R2
ALTER DATABASE AdventureWorks2008R2
SET ENCRYPTION ON
 GO					  

After you enable TDE, you might want to monitor the progress of the encryption. This can be done by running the following query:

SELECT DBName = DB_NAME(database_id), encryption_state
FROM sys.dm_database_encryption_keys ;
GO

DBName               encryption_state
-------------------- ----------------
tempdb               3
AdventureWorks2008R2 3

This query returns the database encryption state. A database encryption state of 2 means that encryption has begun, and an encryption state of 3 indicates that encryption has completed. When the tempdb database and user database you are encrypting reach a state of 3, the entire user database and tempdb database are encrypted.

When TDE is enabled for a given database, encryption is applied to a variety of files related to the database, including the following:

• Database Data Files— All data files that contain the database data are encrypted. These files typically have the extension .mdf or .ndf.

• Database Log Files— The transaction log files are encrypted so that no clear text is visible in the files. These files typically have the extension .ldf.

• Database Backups— All database backups, including full, differential, and log, are encrypted.

• Tempdb— If any databases on a server are encrypted with TDE, the tempdb database is also encrypted.

In addition to these files, you can also manually enable TDE on the distribution and subscriber database involved in replication. This encrypts a portion of data involved in replication, but there are still some unencrypted files. Snapshots from snapshot replication as well as the initial distribution of data for transactional and merge replication are not encrypted.

Managing TDE in SSMS

You can also view and manage transparent data encryption in SQL Server Management Studio. To do so, right-click on the database in the Object Explorer for which you want to configure TDE and select Tasks; then select Manage Database Encryption. If you are setting up the initial configuration for TDE in a database, you see a dialog like that shown in Figure 1.

Figure 1. Enabling TDE in SSMS.

The options available in this dialog correspond to commands shown in Listing 1. You specify the encryption algorithm to be used and the server certificate used to protect the database encryption key. When you are ready to enable TDE for the database, put a check mark in the Set Database Encryption On check box.

If TDE is already enabled for a database, the dialog changes to provide you with options to re-encrypt the database encryption key and to regenerate the DEK using a different encryption algorithm. You can also enable/disable database encryption (see Figure 2). A second page displays the current TDE properties and encryption state of the database (see Figure 3).

Figure 2. Modifying TDE properties in SSMS.

Figure 3. Viewing TDE properties in SSMS.

Backing Up TDE Certificates and Keys

The most important issue to consider when using TDE is that you must back up and retain the certificate and private key associated with the encryption. If these things are lost or unavailable, you are not able to restore or attach the encrypted database files on another server. The following warning message displayed after creating a certificate drives home this point:

Warning: The certificate used for encrypting the database
encryption key has not been backed up. You should immediately
back up the certificate and the private key associated with the
certificate. If the certificate ever becomes unavailable or if you
must restore or attach the database on another server, you must have
backups of both the certificate and the private key or you will not
be able to open the database.
Backup up the certificate and private key

Backing up the certificate, private key, and master key for the server is relatively straightforward. An example of backing up the master key is shown in the following SQL statement:

BACKUP MASTER KEY TO FILE = 'c:\mssql2008\backup\masterkey'
    ENCRYPTION BY PASSWORD = 'somekeybackuppassword$$'

Backing up the certificate and associated private key also uses the BACKUP command. The following example backs up the certificate created in Listing 12.1:

BACKUP CERTIFICATE MyCertificate TO FILE = 'c:\mssql2008\backup\MyCertificate'
    WITH PRIVATE KEY ( FILE = 'c:\mssql2008\backup\MyCertificatePrivateKey' ,
    ENCRYPTION BY PASSWORD = 'somecertbackuppassword$$' )


					  

If you want to restore a database backup on another server instance, a master key for the server must exist. If one does not exist, you can create one by using the CREATE MASTER KEY ENCRYPTION syntax. After creating the master key, you are able to create the TDE certificate from a backup of the certificate from the original SQL Server instance, as shown in the following example:

     FROM FILE = 'c:\mssql2008\backup\MyCertificate'
     WITH PRIVATE KEY (FILE = 'c:\mssql2008\backup\MyCertificatePrivateKey',
     DECRYPTION BY PASSWORD = 'somecertbackuppassword$$')


					  

After the certificate is restored on the other server instance, you can restore the encrypted database backup. At this point, the restore can be performed just as you would restore any unencrypted database backup. The restored database is also encrypted and behaves like the original TDE database.

TDE is a relatively simple and effective way to encrypt and protect your data. Other encryption methods that exist with SQL Server can protect different elements of your database. Encryption can be applied to columns of data, an entire table, as well as the communication that occurs between databases and the clients that access them. The level of encryption and need to use it depend on the type of data you are securing.

Limitations of TDE

Although TDE offers many benefits over column-level encryption, it has some of its own limitations, which are important to consider. They include

• TDE is not granular like column-level encryption. The entire database is encrypted, but only on disk. Sensitive data such as Social Security numbers or credit card numbers can be seen by anyone who has permission to access those columns. TDE also does not prevent DBAs from viewing any data in the database.

• TDE does not protect communications between client applications and SQL Server. Network encryption methods should be used to protect sensitive data flowing over the network.

• FILESTREAM data is not encrypted.

• When any one database on a SQL Server instance has TDE enabled, the tempdb database is also automatically encrypted. This can affect performance for both encrypted and nonencrypted databases running on the same instance.

• Databases encrypted with TDE can’t take advantage of SQL Server 2008’s new backup compression. If you want to take advantage of both backup compression and encryption, you have to use a third-party application, such as Idera’s SQL Safe Backup or Redgate’s SQL Backup, which both have the capability to both compress and encrypt backups.